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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



I'd . 



The present document is 3 part of a multi-part conformance test specification for UE and is valid for 3GPP Release 5 
and above. The specification contains a TTCN design frame work and the detailed test specifications in TTCN for the 
UE conformance at the Gm reference point. 

3GPP TS 34.229-1 [5] contains a conformance test description in prose. 

3GPP TS 34.229-2 [6] contains a pro-forma for the UE Implementation Conformance Statement (ICS). 

3GPP TS 34.229-3 the present document. 
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Scope 



The present document specifies the protocol conformance testing in TTCN for the 3GPP User Equipment (UE) at the 
Gm interface. 

The present document is the 3"* part of a muhi-part test specification, 3GPP TS 34.229. The following TTCN test 
specification and design considerations can be found in the present document: 

the overall test suite structure; 

the testing architecture; 

the test methods and PCO definitions; 

the test configurations; 

the design principles, assumptions, and used interfaces to the TTCN tester (System Simulator); 

TTCN styles and conventions; 

the partial PIXIT proforma; 

the TTCN files for the mentioned protocols tests. 

The Abstract Test Suites designed in the document are based on the test cases specified in prose 
(3GPP TS 34.229-1 [5]). 

The present document is valid for UE implemented according 3GPP Release X, where X is the Release indicated on the 
spec's front page. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and 
3GPPTS 34.229-1 [5] apply. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and 3GPP TS 34.229-1 [5] 
apply. 



4 Requirements on the TTCN development 

A number of requirements are identified for the development and production of TTCN specification for 3GPP UE at the 
Gm reference point. 

1. Top-down design, following 3GPP 34.229-1 [5], 3GPP TS 34.123-1 [2], 3GPP TS 34.108 [7]. 

2. A unique testing architecture and test method for testing all protocol layers of UE. 

3. Uniform TTCN style and naming conventions. 

4. Improve TTCN readability. 

5. Using TTCN-3 (ES 201 873-1 [12]). 

6. TTCN specification feasible, implementable and compilable. 

7. Test cases shall be designed in a way for easily adaptable, upwards compatible with the evolution of the 3GPP 
core specifications and the future Releases. 

8. The test declarations, data structures and data values shall be largely reusable. 



£75/ 



3GPP TS 34.229-3 version 9.8.0 Release 9 1 ETSI TS 1 34 229-3 V9.8.0 (201 3-07) 

9. Modularity and modular working method. 

10. Minimizing the requirements of intelligence on the emulators of the lower testers. 

11. Giving enough design freedom to the test equipment manufacturers. 

12. Maximizing reuse of RFC BNF definitions from the relevant IETF core specifications. 

In order to fulfil these requirements and to ensure the investment of the test equipment manufacturers having a stable 
testing architecture for a relatively long period, a unique testing architecture and test method are applied to the 3GPP 
UE protocol tests. 

5 Test method and test model 

5.1 Test method 

5.2 IMS CC test model 

The test model is shown in figure 2. 

5.2.1 Ports interfacing to SS 

In TTCN-3, ports are defined in all test components and in the Test System Interface. This is the equivalent of PCOs in 
TTCN-2. These ports then have to be mapped, or connected, to the SS at the start of each test. 

5.2.1.1 Data ports 

IMS_CC ATS in TTCN-3 simulates the SIP behaviour at the P_CSCF side. TTCN-3 communicates with the UE under 
test through four data ports and the emulations beneath. Each port shall be able to distinguish the use of one of the dual 
protocol stacks of IPv4 / IPv6. 

The type of port (client or server) used to send or received a message will depend on the transport protocol selected for 
the testing, i.e. UDP or TCP. 

UDP case: The SS will send requests and responses to the UE from its client port. The SS will receive requests 
and responses from the UE on its server port. 

TCP case: The SS will receive requests from the UE and will send responses to those requests on its server port. 
The SS will send requests to the UE and will receive responses to those requests on its client port. 

For SIP requests originated by the UE, the transport protocol in UL is selected by the UE. This information is extracted 
in the TTCN-3 and used in subsequent responses sent by the SS. 

For SIP requests originated by the SS in DL UDP is used as transport protocol at the test For the purpose of test 
coverage, TCP is used in the specifictest cases as specified. 

NOTE: According to RFC 3261 [16] clause 18.1.1 the server side (UE) has to be able to cope with a maximum 

datagram size of 65,535 bytes (independent of any guideline to restrict the maximum size of UDP packets 
at the client side). 

If no security associations have been set up, the unprotected client and server ports will be used. The security ports shall 
be used by the TTCN-3 authors when a security association has been established. 

5.2.1 .2 Security Associations Setup 

Four unidirectional SAs are established between the UE and the SS: 

SAl: port_uc to port_ps 
SA2: port_pc to port_us 
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SA3: port_ps to port_uc 
SA4: port_us to port_pc 

The first pair (SAl and SA3) is for bidirectional traffic between port_uc and port_ps. The second pair (SA2 and SA4) is 
for bidirectional traffic between port_pc and port_us. 

While TCP scenario will use all four SAs, in UDP, only two S As are needed because there is no traffic from port_ps to 
port_uc nor from port_us to port_pc. Figure 1 shows one example of the use of ports and security association in UDP 
and TCP. 



UDP case 



TCP case 
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Unprotected client port 
Unprotected server port 

port_uc 

port_us 

port_us 

port_uc 



Register 
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OK. __. 

SA2 spi_us 
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180 Ringing 
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Unprotected server port 
Unprotected client port 
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port_us 
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RANDIIAUTN 



...^.?.SJ?ter.__ _^^___ 



SAl spi_ps 
OK 
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Invito 
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_ 18_0_Ringing_ _ 



_ 200 OK 
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Unprotected server port 
Unprotected server port 
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port_ps 

port_pc 



port_pc 



Unprotected 

Protected by SA pair 1 

Protected by SA pair 2 



Figure 5.2.1 .2-1 : Use of port and SA in UDP and TCP 



5.2.1.3 



Control ports 



IMS_CC ATS also controls the SS configuration and passes necessary parameters to the various emulation entities in 
the SS. This is done by ASPs through an IP-CAN control port, an IP configuration port and a Signalling 
Compression control port. 

From the protocol stack point of view, SIP is an application layer protocol located above transport layer UDP / TCP 
which in turn use the services provided by the IP/IPsec layer. The IP packages are transmitted via the connected IP- 
CAN bearer, the EUTRA bearer, the UTRA bearer or the GERAN bearer. The emulations of these protocol layers in the 
SS shall be compliant with the relevant core specifications (3GPP and IETF). 

The IP-CAN bearers are created, configured, modified and released though the ASP at the IP-CAN control port. The 
TTCN-3 codes shall also be able to control the UDP/IP/IPsec configurations and provide necessary parameters through 
the control ASPs. 

The configuration of IP-CAN in the SS depends upon the technologies the UE supports. E-UTRA shall be configured 
for IMS test if E-UTRA technology is supported by the UE. 
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Figure 5.2.1 .3-1 : IIVIS CC test model 



5.2.2 SAD 

Security Association Database (SAD) shall be made accessible by the IPsec entity and contain sets of parameters 
corresponding to each security association. During registration/authentication, the UE and the SS will negotiate these 
parameters for setting up a security association. As the negotiation is carried out on SIP level (through SIP message 
exchanges), the resulting security parameters are obtained and stored in IMS_CC ATS. A number of ASPs are defined 
to convey these parameters from TTCN-3 codes to SAD. ASPs manipulating the SAD are also defined. 

5.2.3 Network interface 

Similar to the majority of TCP/IP stack implementations, a network interface (IFO, IFl, IF2, etc.) structure is used to 
connect the IP -CAN bearer to IP protocol entity. When the ASP for setting up an IP -CAN bearer is called via the 
IP-CAN control port, the SS shall connect the established radio access bearer to the relevant IF structure, in order to 
provide the radio bearer connectivity to the IP/IPsec layer. In order to ease maintenance, all IP -CAN control has been 
encapsulated into its own Parallel Test Component. 



5.2.4 SigComp and related control port 



SIP Compression is mandatory (clause 8 of 3GPP TS 24.229) and Signalling compression (RFC 3320, RFC 3485, 
RFC 3486, RFC4896, RFC5049) protocol is used for SIP compression. The SigComp entity in the model is used to 
carry out the compression/decompression functions. In the receiving direction of the SS, the SigComp entity will detect 
whether the incoming SIP message is compressed and, if so, decompress it. In the sending direction of the SS, the 
TTCN controls whether the outgoing SIP message is compressed through the SigComp control port. If while 
decompressing a message, decompression failure occurs, the message shall be discarded. The SigComp layer in the SS 
shall automatically find if a secure port or un-secure port is being used for transmission or reception of messages. If an 
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un-secure port is used for transmission, then as per clause 8 of 3GPP TS 24.229, it shall not include state creation 
instructions. If the state creation command is received in a compressed message on an un-secured port (clause 8 of 
3GPP TS 24.229), a decompression failure shall be generated. 

5.2.5 SIPTTCNSCodec 

SIP is a text-based protocol, the messages exchanged between the UE and the SS are character strings. In TTCN-3 ATS 
the messages are structured to take the advantage of TTCN-3 functionality, and to make the debugging and maintenance 
of the ATS easier. When the TTCN-3 ATS sends a message to the UE, the SIP TTCN-3 codec converts the structured 
message to the corresponding character string then transfers it to the UE. When the SS receives a message from the UE, 
the TTCN-3 codec converts the received character string to the structured message and passes it to the TTCN-3 ATS. 

5.2.6 DHCP and DNS data ports 

The DHCP port is used for receiving the DHCP requests from the UE under test, and sending corresponding responses 
to the UE. The DNS port is used for receiving domain name resolution requests from the UE and sending the results 
back to the UE. The TTCN which implements the required DHCP and DNS server functions (only the functions 
necessary for testing purposes, not full functionality) will receive and send on these ports. 

The DHCP and DNS server functionalities in the default test configuration are implemented as Parallel Test 
Components (PTCs). 



5.3 Upper Tester (UT) 



In order to support test automation and regression testing, there is an MMI port through which MMI commands (e.: 
"Please initiate a call") are sent to an external entity of the system simulator. Implementations can customize the 
external entity according to their needs. 

5.4 TTCN-3 

TTCN is used as specification language. ES 201 873 [12] (TTCN-3) is applied to the notation. 



5.5 Support of XCAP 



MTSI supplementary services (TS 24.173) like communication barring (CB) and communication diversion (CDIV) 
require the XCAP protocol (RFC 4825) for transporting and manipulating XML documents in the network describing 
these services. Test cases for these services are specified in TS 34.229-1 clause 15. In order to support test case 
development, the test model shown in Figure 2 describes a PTC to handle HTTP requests from the UE and an external 
XCAP server as illustrated in Figure 3 below. There are specific ASPs to communicate with the XCAP server and for 
configuring the HTTP layer and for transferring data from the TTCN engine to the HTTP layer. 

Figure 3 shows the Http/TLS layer of the test model within the SS connected to the TTCN component executing the 
testcases; and to the new BSF module (Bootstrapping Server Function, see TS 33.220) needed for implementing the 
GAA authentication. 
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Figure 3: Extension to the Test lUlodel to support XCAP 



5.5.1 

5.5.2 XCAP server functionality 

RFC 4825 specifies the protocol for accessing user data in the XCAP server via HTTP requests. An HTTP request for 
an XCAP operation contains basically three components: 

- Request line method, i.e. PUT, GET or DELETE 

Request line uri - The XCAP expression to be evaluated to access the XCAP document. The XCAP expression 
consists of the document selector followed by the separator ' — ' followed by the node selector pointing to the 
user data to accessed or evaluated 

body - Describing the value (an xml fragment) referenced by the XCAP expression 

Supplementary Services test cases (e.g. 34.229-1 test 15.1) verify the correct UE"s XCAP signalling. Because TTCN is 
not suited for accessing and processing complex XML data, the XML processing relies on an external XCAP server 
simulation. 

Example 1 

In order to set terminating-identity-presentation for user sip:ob. stfl60@etsi.org, the UE sends following HTTP request: 

PUT http : //XCAP- Server/ simservs .ngn. etsi .org/users/sip%3Aob .stfl60%40etsi. org/simservs .xml/~~ 
/ s imservs/ terminating- identity-present at ion/ %4 active 
Body: true 

If successful, the XCAP server responds with 

HTTP/ 1.1 200 OK 
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Example 2 

To get the value of terminating-identity-presentation for user sip:ob. stfl60@etsi.org, the UE sends following HTTP 
request: 

GET http : //XCAP- Server/ simservs .ngn. etsi .org/users/sip%3Aob .stfl60%40etsi .org/simservs .xml/~~ 
/ s imservs/ terminating- identity-present at ion/ %4 active 

If successful, the XCAP server responds with 

HTTP/ 1.1 200 OK 
Body: true 

In this example 

//XCAP -server/ simservs .ngn. etsi . org/users/ sip%3Aob .stfl60%40etsi .org/simservs .xml/- 

Dociunent selector for user sip :ob . stf 160@etsi . org. 

— - Document selector separator, see RFC 4825 

/simservs/terminating-identity-presentation/%40active - Node selector pointing to the information in 

the XCAP server to be accessed. This is an XPATH expression, see RFC 4825 section 6.3. 

true - Is the xml fragment {in this case very simple) to be set as value of the XPATH expression 

Following operations shall be implemented in the XCAP server, see RFC 4825. 
GET - Returns the requested data as an XML fragment to be send to the UE 

input parameters: charstring documentSelector, charstring xpathExpr 
output parameters: error code {0 = noError) 
returns : XML fragment or XML document 

PUT - Builds an XML subtree or sets an attribute given by the xmlFragment at the position pointed by 
the xpath expression 

input parameters: charstring documentSelector, charstring xpathExpr, charstring xmlFragment or 

xmlDocument 

returns: error code {0 = noError) 

DELETE - Deletes an XML subtree or sets an attribute given by the xmlFragment at the position 
pointed by the xpath expression 

input parameters: charstring documentSelector, charstring xpathExpr 
returns: error code {0 = noError) 

RESET - This is not an XCAP operator but needed to generate in the XCAP server a default document 

for a particular user during the preamble 

input parameter: charstring documentSelector 

returns: error code {0 = noError) 

Default simservs XML document referenced by the documentSelector: 

<?xml version="l . 0" encoding="UTF-8" ?> 

< simservs xmlns="http : //uri .etsi .org/ngn/params /xml /s imservs /xcap" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

<communication-waiting active="true"/> 

< originating- identity-presentation active="true"/> 

<originating- identity-present at ion- restrict ion active="true"> 

<def ault- behaviour >present at ion- restrict ed< /default -behaviour > 

< /originating- identity-present at ion- res triction> 

<terminating- identity-presentation active="true"/> 

< terminating- identity-present at ion- restrict ion active="true"> 

<def ault -behaviour >present at ion- restrict ed< /default -behaviour > 

< /terminating- identity-presentation- restrict ion> 
</simservs> 

The XCAP server simulation shall return different error codes to inform TTCN on the result of the operation: 

- Success 

1 - User document not found 

2 - Invalid XCAP expression 

3 - Invalid xmlFragment 

4 - Invalid document ( not complying to the XSD schema of the sub-document related to the particular XCAP 

service) 

Further error codes are FFS 
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5.6 Extension of the Test Model to support 36.523-3 Interface 

The IMS CC test cases can also be executed on top of the 36.523-3 test model. To support this approach, the following 
test model is used. 
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Figure 5.6-1 : Extension to the Test lUlodel to support 36.523-3 SS interface 



The IMS CC test cases run on the IMS-PTC which control the IPCanEmu and the IP-PTC. IPCanEmu is responsible for 
cell setup and DRB establishment and the IP-PTC controls the IP related configurations. IPCanEmu and IP-PTC 
interface to the SS according to 36.523-3. 

Clauses 4.2.4 and 4.2.5 of 36.523-3 describe the common handling of IP data in the 36.523 model regarding IMS 
signalling. In addition when a test case requires support of XCAP the SS needs to extend routing and handling of the IP 
data so that it can manange the security for the respective HTTP data, provide information of HTTP request and process 
information for HTTP responses according to ASP definitions in clause 6.4. The configuration of this extension is done 
by HttpCtlReq as defined in clause 6.4. 

Further clarifications are FFS. 



ASP definitions 



6.1 



Control ASP 



ASPs for configuring/controlling the SS are defined to operate in a pair of ASPs, Req (request) ASP and Cnf (Confirm) 
ASP of the blocking mode. The TTCN-3 execution after sending a Req ASP shall wait (be blocked) for the Cnf ASP. 
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Because the IMS Test Suite is radio access technology independent, few parameters are passed from the TTCN-3. 
Therefore the exact configuration procedures used are determined by the implementation. 

The PIXIT px_RANTech (see below) is set by the operator according to the technology the UE supports and is passed 
through the TTCN to the SS. This is defined as an enumerated type and is used to specify which platform the test is to 
be run on (e.g. GERAN, UTRA or E-UTRA). E-UTRA shall be chosen if it is supported by the UE. 

6.1.1 Cell Control 



Name 


CreateCellReq 


Port 


IPCANctI 


Comment 


ASP type for creating a cell 


Parameter Name 


Parameter Type 


Comment ■ 


ranlech 


RANTech 




primaryFrequencyBand 


integer 




union { 

noSSAC, 

ssacBarringFactorVoice, 

ssacBarringFactorVideo 

} 




Optional. 

Specific ac-Barring Factor 


mccValue 


hexstring (3) 


Optional 


mncValue 


hexstring (2. .3) 


Optional 





CreateCellCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of CreateCellReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





Name 


ReleaseCellReq 


Port 


IPCANctI 


Comment 


ASP type for releasing resources allocated to the cell 


Parameter Name 


Parameter Type [Comment ^^~ 



Name 


ReleaseCellCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of ReleaseCellReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





Name 


RANTech 


Type 


enumerated 


Parameters 


GERAN, UTRA_FDD, UTRA_TDD, EUTRA_FDD, EUTRA_TDD, 
dummyl, dummy2 


Comment 


Indicates the radio access network technology used for transport of 
SIP signalling messages over the air interface 



Name 


Status 


Type 


enumerated 


Parameters 


success, failure, inconclusive 


Comment 


Indicates the status result of the requesting ASP 
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Name 


ModifyCellReq 


Port 


IPCANctI 


Comment 


ASP type for modifying system information parameters in a cell 


Parameter Name 


Parameter Type 


Comment " 


union { 
noSSAC, 

ssacBarringFactorVoice, 
ssacBarringFactorVideo 
} 




Optional. 

Specific ac-Barring Factor 



Name 


ModifyCellCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of IVIodifyCellReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





6.1.2 IdleUpdated 



Name 


IdleUpdatedReq 


Port 


IPCANctI 


Comment 


ASP type which requests the SS to bring the UE into an idle updated 
state and GMM or EIVIM registered 


Parameter Name 


Parameter Type 


Comment 


ue Address 


IPAddress 


UE address to be assigned via 
NAS signalling 


bearerlnfo 


List of integers 


Optional. For use in EUTRA to 
specify the default bearer to be 
used and possibly one or more 
dedicated bearers to be 
established in the preamble. 


isEmergency 


Boolean 


Optional. To indicate if this is an 
emergency attach 


wIthUICC 


Boolean 


Optional. To indicate If the UE 
hasaUICC 



Name 


IdleUpdatedCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of IdleUpdatedReq 


Parameter Name 


Parameter Type 


Comment ■ 


status 


Status 





Name 


Detach Req 


Port 


IPCANctI 


Comment 


ASP type which requests the SS to bring the UE into detached state 


Parameter Name 


Parameter Type 


Comment 


moFlag 


Boolean 


Set to true if th SS is requested to 

accept a mobile originated 

detach. 

Set to false if the SS is requested 

to initiate the detach 



Name 


DetachCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of DetachReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 
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Name 


HandoverReq 


Port 


IPCANctI 


Comment 


ASP type which requests the SS to allow the UE to handover to 
another RAT 


Parameter Name 


Parameter Type 


Comment 


ranTech 


RANTech 


Info to which RAT the UE will 
handover 


handoverType 


HandoverType 


Type of handover 



Name 


HandoverCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of HandoverReq 


Parameter Name 


Parameter Type 


Comment ■ 


status 


Status 





Name 


HandoverType 


Type 


enumerated 


Parameters 


ho csfb, ho reselection 


Comment 


Indicates the type of handover to be performed 



6.1.3 PDPContext 



Name 


AddPDNReq 


Port 


IPCANctI 


Comment 


ASP type which requests the SS to be prepared to establish a new 
PDN 


Parameter Name 


Parameter Type 


Comment ^ 


ue Address 


IPAddress 


UE address to be assigned via 
NAS signalling 


isEmergencyPDN 


Boolean 


To indicate if this is an 
emergency bearer 




Name 


AddPDNCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of AddPDNReq 


Parameter Name 


Parameter Type 


Comment | 


status 


Status 






Name 


POORequest 


Port 


IPCANctI 


Comment 


ASP type which returns the contents of the 
ProtocolConfigurationOptions IE received in the 
ActivatePDPGontextRequest / EPS Bearer Request to the TTCN 


Parameter Name 


Parameter Type 


Comment 


configOptList 


ConfigOptList 




bearerContextId 


integer 






Name 


PCOResponse 


Port 


IPCANctI 


Comment 


ASP type which sends back the ProtocolConfigurationOptions IE to 
the SS. 


Parameter Name 


Parameter Type 


Comment 


configOptList 


ConfigOptList 




bearerContextId 


integer 
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Name 


DedicatedBearerReq 


Port 


IPCANctI 


Comment 


ASP type which in requests the SS to establish one or more 
secondary PDP context / dedicated bearers; or informs the SS to 
expect the UE to request one or more secondary PDP context / 
dedicated bearers. Includes the bearer info to be configured and 
media ports to be used 


Parameter Name 


Parameter Type 


Comment 


bearerlnfoList 


{{bearerContextId, 

bearerlnfo, 

mediaPort}} 




moFlag 


boolean 


Set to true if the SS is requested 
to accept a mobile initiated 
dedicated bearer establishment 
procedure; set to false if the SS is 
to establish the dedicated bearer. 



Name 


DedicatedBearerCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
DedicatedBearerReq, when it is completed 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





Name 


ModifyBearerReq 


Port 


IPCANctI 


Comment 


ASP type which informs the SS to expect the UE to request to modifiy 
an existing PDP context / Dedicated Bearer. Includes the bearer info 
for this to be modified to 


Parameter Name 


Parameter Type 


Comment 


bearerContextId 


integer 




bearerlnfo 


integer 





Name 


IVIodifyBearerCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
IVIodifyBearerReq, when it is completed 


Parameter Name 


Parameter Tvd^^ 


^mment 


status 


Status 





Name 


DeactivateBearerReq 


Port 


IPCANctI 


Comment 


ASP type which requests the SS deactivate the indicated PDP 
context. A value of bearerContextId = indicates that all existing 
PDP contexts are to be deactivated. 


Parameter Name 


Parameter Type 


Comment 


bearerContextId 


integer 




molnititiated 


boolean 


Flag indicating if the PDP context 
deactivation is initiated by the UE 



Name 


DeactivateBearerCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
DeactivateBearerReq 


Parameter Name 


Parameter Type 


Comment ^^^^^^^^ 


status 


Status 
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Name 


Bearerlnfo 


Type 


integer 


Comment 


References the RAB to be configured. Tliis is RAN independent and 
can be added to/reduced as required 



This is simply a list of RAB identifiers. It is expected, in the future, for these identifiers to equate to specific RAB 
requirements, for all available radio access technologies See clause 8.1 for more information. 



Name 


ConfigOptList 


Type 


set of ConfigOpt 


Comment 


Used to contain tlie protocol configuration options IE used in the PDP 
context messages 



Name 


ConfigOpt 


Type 


octetstring 


Parameter Name 


Parameter Type 


Containerld 


octetstring [2] 


ContainerLength 


octetstring [1] 


ContainerContents 


octetstring optional 



6.1.4 IP Configuration 



Name 


InstallKeyReq 


Port 


IPconf 


Comment 


ASP type which installs the keys into the IP layer in the SS 


Parameter Name 


Parameter Type 


Comment 


MD5 96Key 


bitstring 


length (128) 


SHA 1 96Key 


bitstring 


length (160) 


DES EDE3 CBCKey 


bitstring 


length (192) 


AES CBCKey 


bitstring 


length (128) 



Name 


InstallKeyCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of InstallKeyReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





Name 


AssignlPaddrReq 


Port 


IPconf 


Comment 


ASP type which assigns the IP address to the IP layer in the SS 


Parameter Name 


Parameter Type 


Comment 


p cscf Addr 


IPAddr 




dhcp Addr 


IPAddr 




dns Addr 


IPAddr 




ue Addr 


IPAddr 




peerUE Addr 


IPAddr 





Name 


AssignlPaddrCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of 
AssignlPaddrReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





Name 


IPAddr 


Type 


charstring 


Comment 


in either colon separated or dotted decimal format 
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Name 


ReleaselPConfigurationReq 


Port 


IPconf 


Comment 


ASP type which releases the IMS IP layer configurations including 
Security Associations. This ASP is meant to be used when starting a 
new test case to make sure that the IP layer is in a well defined initial 
state irrespective of the execution of previous tests. 


Parameter Name 


Parameter Type 


Comment ^^^^^^^H 


- 


- 


No parameters 




Name 


ReleaselPConfigurationCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of 
ReleaselPConfigurationReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 






Name 


AddPCSCFaddrReq 


Port 


IPconf 


Comment 


ASP type which configures a new address of the P-CSCF component 
in the IP layer in the SS 


Parameter Name 


Parameter Type 


Comment 


p_cscf_Addr 


IPAddr 


New IP address of P-CSCF 
component to be simulated 




Name 


AddPCSCFaddrCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of 
AddPCSCFaddrReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 






Name 


SignallingCompressionReq 


Port 


SigComp 


Comment 


ASP type which starts/stops signalling compression of messages 


Parameter Name 


Parameter Type 


Comment 


startCompression 


boolean 






Name 


SignallingCompressionCnf 


Port 


SigComp 


Comment 


ASP type which returns the result of the execution of 
SignallingCompressionReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 






Name 


RcvdCompartmentId 


Port 


SigComp 


Comment 


ASP type which feeds back the Compartment Id back to the Sigcomp 
layer, extracted from the last received message, used by SigComp 
layer to store any state appropriately. 


Parameter Name 


Parameter Type 


Comment 


compartmentid 


charstring 


Call-Id of the SIP message will be 
used as compartment Id 
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Name 


DecompFailureType 


Type 


enumerated 


Parameters 


stateCreation,dummy1,dummy2,dummy3 


Comment 


Indicates the mechanism through which decompression failure errors 
shall be inserted during compressing message 
stateCreation: This type indicates, decompression failure shall be 
generated by inserting "State Creation" instructions in DL messages 
sent on unsecured SS Port (clause 8 of 3GPP TS 24.229) 



Name 


UpdateRemotePCSCFPortNumberReq 


Port 


IPconf 


Comment 


ASP type use by TTCN to reconfigure P-CSCF server and client 
ports to contact the UE at given port number 


Parameter Name 


Parameter Type 


Comment 


uePortNumber 


integer 





Name 


UpdateRemotePCSCFPortNumberCnf 


Port 


IPconf 


Comment 


ASP type which the result of the execution of 
UpdateRemotePCSCFPortNumberReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





6.1.5 SA Database 



Name 


DoubleAddSADReq 


Port 


IPconf 


Comment 


ASP type which sets two entries of SAD in the SS 


Parameter Name 


Parameter Type 


Comment 


sa1 


SA 




sa2 


SA 





Name 


DoubleAddSADCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of 
DoubleAddSADReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 







DelSADReq 


Port 


IPconf 


Comment 


ASP type which deletes the SAD entries 


Parameter Name 


Parameter Type 


Comment 


spil 


SPI 




spi2 


SPI 


optional 


spi3 


SPI 


optional 


spi4 


SPI 


optional 


spi5 


SPI 


optional 


spi6 


SPI 


optional 


spi7 


SPI 


optional 


spiS 


SPI 


optional 


spi9 


SPI 


optional 



Name 


DelSADCnf 


Port 


IPconf 


Comment 


ASP type which returns the result of the execution of DelSADReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 
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Name 


SA 


Port 


IPconf 


Comment 


ASP type which sets a single entry of parameters for a security 
association in the SS 


Parameter Name 


Parameter Type 


spi 


SPI 


srclPaddr 


IPAddr 


deslPaddr 


IPAddr 


srcUDPport 


integer 


desUDPport 


integer 


intAlgo 


IntAlgo 


ciphAlgo 


CiphAlgo 




Name 


IntAlgo 


Type 


enumerated 


Parameters 


hmac md5 96, hmac sha 1 96 


Comment 


Integrity algorithms 




Name 


CiphAlgo 


Type 


enumerated 


Parameters 


des ede3 cbc, aes cbc, nociph 




Ciphering algorithms, "nociph" means no ciphering 




Name 


SPI 


Type 


integer (0..4294967295) 


Comment 


security parameter index for IPsec 



6.1.6 Emergency CS Call 



Name 


ExpectEmergencyCSCall 


Port 


IPCANctI 


Comment 


ASP type which informs the SS to expect the UE to request an 
emergency CS call 


Parameter Name 


Parameter Type Comment 



Name 


EmergencyCSCallActive 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
ExpectEmergencyCSCall when it is in call active state 


Parameter Name 


Parameter Type 


Comment j 


status 


Status 





Name 


ReleaseCSCallReq 


Port 


IPCANctI 


Comment 


ASP type which requests the SS to release the CS call previously 
established during ExpectEmergencyCSCall 


Parameter Name 


Parameter Type Comment 



Name 


ReleaseCSCallCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
ReleaseCSCallReq 


Parameter Name ^^^ 






status 


Status 
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6.1.7 CS Voice Call 



Name 


CSCallReq 


Port 


IPCANctI 


Comment 


ASP type which informs the SS to establish a CS voice call with the 
UE 


Parameter Name 


Parameter Type 


Comment 


moFlag 


Boolean 


Set to true if the SS is requested 
to accept a mobile originated CS 
voice call; 

Set to false if SS is requested to 
establish a CS voice call 


phoneNumber 


charstring 


Optional. The phone number to 
be signalled to the UE in the 
mobile terminated case 



Name 


CSCallCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of CSCallReq 
when it's in call active state 


Parameter Name 


Parameter Type 


Comment _ 


status 


Status 





6.2 



IMS-CC Data ASP definitions 



6.2.1 ASP_DataRequest 



Name "^^^^^■" 


ASP DataRequest 


Port 


DataPort 


Comment 


ASP type for receiving/sending SIP Request IVIessages 


Parameter Name 


Parameter Type 


Comment 


sigComplnfo 


SigComplnfo 


OPTIONAL. Information for/from 
SigComp layer. Absence means 
compression is/shall be not 
applied in received/send 
message. 


port Info 


SSPortlnfo 




msg 


union {REGISTER Request, 
INVITE Request, 
OPTIONS_Request, 
BYE Request, 
CANCEL_Request, 
ACK_Request, 
PRACK Request, 
NOTIFY Request, 
SUBSCRIBE Request, 
PUBLISH Request, 
UPDATE_Request, 
REFER Request , 
MESSAGE Request} 


SIP message 
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6.2.2 ASP_DataResponse 



6.3 



Name 


ASP DataResponse 


Port 


DataPort 


Comment 


ASP type for receiving/sending SIP RESPONSE Message 


Parameter Name 


Parameter Type 


Comment 


sigComplnfo 


SigComplnfo 


OPTIONAL. Information for/from 
SigComp layer. Absence means 
compression is/shall be not 
applied in received/send 
message. 


port Info 


SSPortlnfo 




msg 


Response 


SIP RESPONSE message 



Name 


SigComplnfo 


Type 


Union 


Parameter Name 


Parameter Type 


Comment 


compartmentid 


charstring 


Used for Sending messages from 
TTCN. To be used by SigComp 
Layer 


isCompressed 


boolean 


Used for received messages. If 
set, means received message 
was compressed 



Name ^^^^^^F 


SSPortlnfo 


Type 


record 


Parameter Name 


Parameter Type 


Comment ■ 


ipAddr 


IPAddr 


IP address of simulated network 
node 


transportProtocol 


TransportProtocol 





Name 


TransportProtocol 


Type 


enumerated 


Parameters 


UDP, TCP 



Ut ASP definitions 



Name 


MMIIVIessage 


Port 


MMIPort 


Comment 


ASP type for sending messages to upper tester 


Parameter Name 


Parameter Type 


Comment 


mmilVlessage 


charstring 


Action required by upper tester 



6.4 HTTP Layer ASP definitions 

HTTP Layer ASPs are applicable to clause5.2.1.3 and5.6. 





HttpRoutinglnfo 


Comment 


Routing info to distinguish HTTP data for XCAP server and BSF. 


Parameter Name 


Parameter Type 


Comment 


serverAddr 


Charstring 


IP address of simulated server 


xcapServerPort 


Integer 


Port number of simulated server 
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Name 


HttpDataInd 


Port 


HTTP DATA 


Comment 


ASP type for sending a message from the http layer to the TTCN 
engine. It transports relevant information of a http Request from the 
UE to the Tester. 


Parameter Name 


Parameter Type 


Comment 


routinglnfo 


HttpRoutinglnfo 


to distinguish BSF and XCAP 
server 


httpRequest 


HttpRequest 


See below 



Name 


HttpRequest 


Comment 




Parameter Name 


Parameter Type 


Comment ■ 


requestLine 


HttpRequestLine 


Request-Line in RFC 2616 [27] 
clause 5.1 


authorization 


Authorization 


Authorization in RFC 2616 [27] 
clause 14.8 (optional; NOTE 1) 


contentType 


ContentType 


Content-Type in RFC 2616 [27] 
clause 14.17 (optional, NOTE 1) 


xSGPPIntendedldentity 


charstring 


3GPP TS 24.1 09 [33] clause G.2 
(optional) 


messageBody 


charstring 


MTSI XCAP Message (optional) 


NOTE 1 : Same type definition as for SIP type definitions. 



Name 


HttpRequestLine 


Comment 


request line according to RFC 2616 [27] clause 5.1. 


Parameter Name, 


Parameter Type 


Comment 


method 


charstring 




uri 


charstring 


XCAP selection expression, RFC 
4825 [26] 


version 


charstring 





Name 


HttpDataReq 


Port 


HTTP DATA 


Comment 


ASP type for sending messages from the TTCN engine to the http 
layer. It transports information needed by the http layer to generate a 
http Response to the UE. 


Parameter Name 


Parameter Type 


Comment ■ 


routinglnfo 


HttpRoutinglnfo 


to distinguish BSF and XCAP 
server 


httpResponse 


HttpResponse 


See below 



Name 


HttpResponse 


Comment 




Parameter Name 


Parameter Type 


Comment 


statusLine 


HttpStatusLine 


Status-Line in RFC 2616 [27] 
clause 6.1 


wwwAuthenticate 


wwwAuthenticate 


www-Authenticate in RFC 2616 
[27] clause 14.47 (optional; 
NOTE 1) 


authenticationlnfo 


Authenticationlnfo 


Authentication-Info in RFC 2617 
[37] clause 3.2.3 (optional; NOTE 
1) 


contentType 


ContentType 


Content-Type in RFC 2616 [27] 
clause 14.17 (optional; NOTE 1) 


expires 


Expires 


Expires in RFC 2616 [27] clause 
14.21 (optional; NOTE 1) 


messageBody 


charstring 


MTSI XCAP Message (XML 
document or XML fragment) 
(optional) 


NOTE 1 : Same type definition as for SIP type definitions. 
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Name 


HttpStatusLine 


Comment 


request line according to RFC 2616 [27] clause 5.1. 


Parameter Name 


Parameter Type 


Comment 


version 


charstring 




code 


charstring 




reasonPhrase 


charstring 





Name 


HttpCtlReq 


Port 


HTTPCTRL 


Comment 


ASP type to configure the http layer 

When any of the optional fields is omitted the SS shall continue with 

the previous configuration of this field. 


Parameter Name 


Parameter Type 


Comment 


authenticationMechanism 


enumerated {noAuthentication, 

httpDigestAuthentication, 

gaaAuthentication} 


Authentication mechanism: 

noAuthentication: 

no authentication (NOTE 3) 

httpDigestAuthentication : 
HTTP digest authentication 
according to 24.623[36] clause 
5.2.3.2 and RFC 261 7 [37] 

gaaAuthentication: 
GAA based authentication 
according to 33.222 [35] and 
24.109 [33] 


tislnfo 


TLSInfo 


Description of the TLS connection 
to be used (optional) 


xcapServer 


HttpRoutinglnfo 


IP address and port of simulated 
XCAP server (optional) 


bsfServer 


HttpRoutinglnfo 


IP address and port of simulated 
BSF server (optional) 


drblnfo 


IP Drblnfo Type 


(optional) NOTE 1 , 2 


NOTE 1 : Whether this parameter is used by the SS depends on SS implementation and on which test 

model is used; if the SS does not need the information it may just ignore it. 
NOTE 2: 'IP_Drblnfo_Type' is imported from common definitions of the LTE model (TS 36.523-3 [30]). 
NOTE 3: in general 'no authentication' is not applicable to conformance testing 



Name 


TLSInfo 


Comment 




Parameter Name 


Parameter Type 


Comment 


tIsType 


enumerated {noTLS, pskTLS, 
certTLS) 


Type of TLS connection to be 
used (if any) 


psk 


octetstring 


Pre shared key for TLS ciphering 


cipherSuite 


enumerated {noCipher, 

psk 3DES EDE CBC SHA, 

psk_AES_1 28_CBC_SHA} 


Cipher suite to be used 



Name 


HttpCtlCnf 


Port 


HTTPCTRL 


Comment 


ASP type to confirm HttpCtlReq 


Parameter Name 


Parameter Type 


Comment _ 


errorlnfo 


charstring 


string indicating a system error 
(optional) 



6.5 XCAP server ASP definitions 

XCAP Layer ASPs are applicable to clause 5.2.1.3 and 5.6. 
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Name 


XCAPReq 


Port 


XCAP 


Comment 


ASP type for sending a request to the external XCAP server 


Parameter Name 


Parameter Type 


Comment ^^H 


method 


charstring 


GET, PUT, DELETE or RESET 


xcapExpression 


charstring 


XCAP expression sent by the UE 
in its http request line 


xmlBody 


charstring 


XIVIL fragment sent by the UE in 
its http body(optional) 


contentType 


charstring 


To distinguish whether the 
xmlBody is an XML fragment or 
an XML document (optional) 




Name 


XCAPRsp 


Port 


XCAP 


Comment 


ASP type for sending the response to the XCAPReq from the XCAP 
server to TTCN 


Parameter Name 


Parameter Type 


Comment „ 


errorlnfo 


charstring 


string indicating a system error 
(optional) 


xmlFragment 


charstring 


Result returned by the XCAP 
server 


contentType 


charstring 


To distinguish whether the 
xmlBody is an XML fragment or 
an XML document 



6.6 Positioning /ASP definitions 



Name 


UpdateUELocationlnfoReq 


Port 


IPCANctI 


Comment 


ASP to trigger in the SS the execution of test function Update UE 
Location Information (TS 36.509 clause 5.5.2) 


Parameter Name 


Parameter Type 


Comment 


ellipsoidPointWithAltitude 


08 Type 


See 56.509 clause 6.12 


horizontalVelocity 


03 Type 


See 56.509 clause 6.12 


gnnTodMsec 


03_Type 


See 56.509 clause 6.1 2 



Name 


UpdateUELocationlnfoCnf 


Port 


IPCANctI 


Comment 


ASP type which returns the result of the execution of 
UpdateUELocationlnfoReq 


Parameter Name 


Parameter Type 


Comment 


status 


Status 





7.1 



Codec definitions for IP User Data 



Introduction 



SIP is a text-based protocol, thus the message exchange between the UE and the SS are pure character strings. In the 
TTCN-3 ATS the messages are structured and optimized to take the advantage of TTCN-3 functionality, and to make 
the debugging and maintenance of the ATS easier. 



7.2 General Aspects 

IP user data for IMS conformance testing can be distinguished into: 
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1. text based: SIP (including SDP and XML messages), HTTP (see clause 7.4) 

2. octetstring based: DHCP, DHCPv6, DNS (see clause 7.4) 
In TTCN the following encoding information is used for user data: 

Table 7.2-1 



Type definitions 


Encoding 


SMS Types 


Tabular notated (see note 1) 


DHCPv4-Codec 


Tabular notated (see note 1) 


DHCPv6-Codec 


Tabular notated (see note 1) 


DNS-Codec 


Tabular notated (see note 1) 


SIPCodec 


(see clause 7.3) 


SDPCodec 


(see clause 7.3) 


HttpCodec 


(see clause 7.3) 



NOTE 1 : Tabular notated is performed by concatenation of all the present fields in the TTCN-3 template. 

NOTE 2: Encoding information is only needed for type definitions of peer-to-peer signalling; encoding of ASPs 
used for system configuration or as co-ordination messages between PTCs is out of scope for this 
document. 

7.3 Requirements on abstract message syntax for IMS (SIP, 
SDP) 

7.3.1 Type definition - Syntax / Semantic aspects 

All given defined BNF grammars (e.g. the ABNF of RFC 3261) are unique. Thus the syntax tree for each syntactically 
correct message derived with these grammars are unique too and the parts of a message can be uniquely identified 
(represented) by the terminal phrase belonging to a non terminal symbol and its derivation path in the syntax tree. 

The syntax tree of all given messages can be used to uniquely identify and describe the parts of the messages. The 
leaves are the part of every message and the nodes from the root to the leaves represent the sequence of rules to be 
applied to derive that part 

The IMS/SIP root message type is an ordered structured type, which is represented as a record type in TTCN-3. For 
each grammar rule of the ABNF a TTCN-3 record type is declared with the specific name of the rule. The following 
rules are applied to the fields within a record: 

A non-terminal symbol is declared as a record type for this symbol. 

The order of the symbols in the rule are represented by an equal order of the fields. 

Repetitions are declared as 'set of or 'record of types. 

Options are represented as optional record/set fields. 

Alternatives are declared as union types. 

7.3.2 Deviations of tine type definition semantic 

Most of the 'literals' of a message (for example: the string "Via" or "v" in the message header fields) are not 
represented. 

- The TTCN-3 charstring type is used where we stop structuring even if the ABNF uses structured types. More 
details found in clause 8.3.3. 

Wherever possible parts are mapped to their best type representation, e.g. DIGIT based rules are mapped to 
integer type not to a charstring type. 
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All of the following delimiters (including preceding or following whitespace) defined by the ABNF grammar to 
separate the parts of a message are not represented (see note). 



STAR 


= 


SWS 


"*" SWS ; asterisk 


SLASH 


= 


SWS 


"/" SWS ; slash 


EQUAL 


= 


SWS 


"=" SWS ; equal 


LPAREN 


= 


SWS 


"{" SWS ; left parenthesis 


RPAREN 


= 


SWS 


")" SWS ; right parenthesis 


RAQUOT 


= 


11 ^ 11 


SWS ; right angle quote 


LAQUOT 


= 


SWS 


"<"; left angle quote 


COMMA 


= 


SWS 


" , " SWS ; comma 


SEMI 


= 


SWS 


" ; " SWS ; semicolon 


COLON 


= 


SWS 


" : " SWS ; colon 


LDQUOT 


= 


SWS 


DQUOTE; open double quotation mark 


RDQUOT 


= 


DQUOTE SWS ; close double quotation mark 


HCOLON 


= 


* { SP / HTAB ) " : " SWS 


SP 


= 


single space 


HTAB 


= 


tab 




SWS 


= 


Sep whitespace 



NOTE: If they are present within a pure charstring they will be handled like a normal character and are still 
included. 

Messages which are not of interest to the test suite are left undecoded as a charstring and will not be 
further structured. 

7.3.3 Additional requirements for codec implementations (SIP/IMS 
Message 

The SIP/IMS codec is based on a normalized encoding which is always produced by an encoder. Decoder 
implementations, however, have to handle normalization before, or when constructing the structured message value, 
e.g. long versus compact form, whitespace compression, delimiter removal, same header grouping, etc. All these 
aspects will be handled in the next clause. 

7.3.3.1 Differences between BNF - TTCN-3 Type Mapping 

In normal cases the mapping is straight forward. Below you find the exceptions, including potential examples. 

The root message type is not a SIP-message but directly a Request or Response type which is represented as a 
TTCN-3 record. All Method - Message names (INVITE, BYE, ACK etc.) and all message header field names 
(To, From, CalllD, CSeq, Via etc.) are mapped to an enumerated type in TTCN-3 to simplify the extension of 
new headers. During encoding, the long-form of these message header fields is always used. The respective field 
in the header type is restricted to values which are allowed. 



BNF rules of RFC 


TTCN-3 Type Mapping 


SIP-message = Request / Response 


type record REGISTER_Request {...}, 
type record INVITE_Request {...}, 
type record PRACK_Request {...}, 
type record NOTIFY_Request {...}, 
type record UPDATE_Request {...}, 

type record Response {...} 



Method = 


INVITEm 


type enumerated Method { ACK E, BYE E, CANCEL E, 




/ACKm 


INVITE E, OPTIONS E, REGISTER E, ...} 




/ OPTIONSm 






/BYEm 






/CANCELm 






/ REGISTERm 





The structure of the message header fields are mapped to a "set " type in TTCN-3, because the order of these 
header fields is not mandatory. There is an Unknown Header List given in the type system to decode unknown 
headers with ID and Value. 
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message-header = 


{ 


type set IVIessageHeader { 




/ Contact 


Contact contact optional, 




/ Content-Disposition 


ContentDisposition contentDisposition optional, 




/ Via 


Via via. 




/ Warning 


Warning warning optional, 




/ www-Authenticate 


WwwAuthenticate wwwAuthenticate optional. 




/ extension-header) CRLF 


UndefinedHeader List undefinedHeader List optional 
} 



The various parameter lists defined in the BNF are mapped and combined into three different TTCN-3 sets of 
generic -param types. These types differ only in their name: SemicolonParam_List, AmpersandParam_List, 
CommaParam_List to distinguish between the relevant separators. 



uri-parameters = *( ";" uri-parameter) 


type set of GenericParam SemicolonParamList; 


Authentication-Info = "Authentication-Info" HCOLON ainfo 
"(COMMA ainfo) 


type record Authentication Info { 

FieldNamefieldName(AUTHENTICATIONJNFO_E), 

CommaParam List ainfo 
1 


ainfo = nextnonce 

/ message-qop 
/ response-auth 
/ cnonce 
/ nonce-count 


type set of GenericParam CommaParam_List; 


Headers = "?" header *( "&" header ) 


type set of GenericParam AmpersandParam_List; 



Any more specific parameter rule (e.g. uri-param, user-param, Ir-param , digest-cln, etc.) is simplified to the 
generic -param rule which will be mapped as a record structure of two charstrings (ID and paramValue). This is 
equivalent to a token with an optional generic value (token [ EQUAL gen- value ]). 



digest-cln = 


realm 


type record GenericParam { 




/domain 


charstring id , 




/ nonce 


charstring paramValue optional 




/ opaque 


} 




/ stale 






/ algorithm 






/ qop-options 






/ auth-param 





In addition to the pure charstring as a base type, the TTCN-3 type system provides base integer types which are 
unrestricted to the model e.g. the portField, CSeq number, maxForward digit. 



user = 1*( unreserved 

/ escaped / user-unreserved 

) 
telephone-subscriber as defined in RFC 2806 


charstring 


password = *( unreserved 
/ escaped 
/"&" 
/ "=" 
/ "+" 
/ "$" 
/ "," 
) 


charstring 
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Port = 


rDIGIT 


integer 


Status-Code = 


Informational 
/ Redirection 
/ Success 
/ Client-Error 
/ Server-Error 
/ Global-Failure 
/ extension-code 


integer 



Where the same header type can appear multiple times within a message, they will be decoded as a single header 
field, with multiple list elements. The order of appearance of the headers will be preserved within the header list 
value. 



Contact = ("Contact" / "m" ) HCOLON 
( STAR / (contact-param 

*(COMMA contact-param) 
) 
) 


type record Contact { 

FieldName fleldName(CONTACT_E), 

ContactBody contactBody 
} 


contact-param = (name-addr / addr-spec) 
*(SEMI contact-params) 


type record ContactAddress { 

Addr_Union addressField, 

SemicolonParam List contactParams optional 
} 

type union ContactBody { 
charstring wildcard, 
ContactAddress List contactAddresses 

} 

Used in 

type set of ContactAddress ContactAddress_List; 



The BNF (clause 7.3.1 Header Field Format RFC 3261 [16]) specifies that several WWW or Proxy 
Authentication/ Authorization headers should not be combined into a single header; however they will be 
decoded into such in the codec. If these need to be sent downlink then a new, 'raw' (pure charstring) message 
type will be introduced. 



Authorization : 



"Authorization" HCOLON credentials 



type record Authorization { 
FieldName fieldName(AUTHORIZATION_E) 
Credentials body 

] 



Credentials = ("Digest" LWS digest-response) 

/ other-response 



type union Credentials { 
CommaParam_List digestResponse, 
OtherAuth otherResponse 
] 



The different schemes (sip, sips, tel, fax, absoluteUri) in the SIP URI are all handled via the same type 
definition. The union 'UriComponents' can be enhanced to support further specific URI formats. Nevertheless it 
is possible to use the 'other' branch of 'UriComponents' for any other URI format in which case the charstring 
shall contain the URI without the scheme and the first ':'. 
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Request-URI = 


SIP-URI 


type record SipUriComponents { 




/SIPS-URI 


//sip-uri ace. to RFC 3261 [16] cl. 19.1 




/ absoluteURI 


Userinfo userinfo optional, 
HostPort hostPort 


with 




} 


SIP-URI = 


"sip:" 


type record TelUriComponents { 




[ userinfo ] 


// tel-uri ace. to RFC 3966 [38] 




hostport 


charstring subscriber 




uri-parameters 


} 




[ headers ] 


type record UrnUriComponents { 


and 




// urn-uri ace. to RFC 2141 [39] 

charstring namespaceld, // e.g. "service" 


SIPS-URI = 


"sips:" 


charstring namespaceSpecificString // e.g. "sos" 




[ userinfo ] 


} 




hostport 






uri-parameters 


type union UriComponents { 




[ headers ] 


SipUriComponents sip, // scheme: "sip" or sips" 
TelUriComponents tel, // scheme: "tel" 


and 




UrnUriComponents urn, // scheme: "urn" 
charstring other 


absoluteURI = 


scheme ":" ( hier-part / opaque-part ) 


} 

type record SipUrl 

{ 
charstring scheme, 

UriComponents components, 
SemicolonParam_List urIParameters optional, 
AmpersandParam_List headers optional 
}type record SipUrl { 

charstring scheme, 

Userinfo userinfo optional, 

HostPort hostPort, 

SemicolonParamList urIParameters optional, 

AmpersandParam List headers optional 

} 



Universal charstrings shall be supported by the codec especially for the Display name in the URL 

For downlink messages, if a message body is included, the TTCN may set the len field in the ContentLength 
header to the value -1. In this case the codec shall replace the value by the actual length of the encoded message 
body (see clause 7.3.4). 

According to the SIP type definitions there are many "charstring" fields being optional in records; 

=:> in UL the decoder shall map missing information by setting the respective field to omit rather than by 

assigning an empty string ("). 

type union Addr_Union 

As in 'NameAddr' the field 'displayName' is optional in the first place the two branches of 'Addr_Union' are 
equivalent when there is no 'displayName'; nevertheless in UL the decoder shall use the branch "nameAddr" if - 
and only if- the address information is surrounded by "<" and ">" (what is needed at least when there is a 
display name followed by the address information) 

IPv6 address in URI 

When an IPv6 address is used as hostname in a SIP URI it is typically surrounded by "[" and "]" what is matter 
of the codec: in DL the codec shall add "[" and "]" when needed, in UL the "[" and "]" shall be removed i.e. in 
the "host" field of the SipUriComponents" hostPort there shall be no "[" or "]" at the beginning or at the end. 

7.3.4 Additional requirements for codec implementations (Message Body) 

The message body of a SIP message may contain the message of other protocols (SDP, SMS, etc.) and can be 
represented e.g. by XML. Therefore the type definitions for these protocols can be TTCN-3 as well as XSD definitions. 
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As in principle the message body of a SIP message may host any XSD definition, SIP and XSD definitions are 

decoupled: 

To avoid import of all potential XSD definitions the XML body of SIP messages is defined as a charstring. This 

requires a two-stage encoding and decoding: In DL an XML message needs to be encoded in TTCN first before it gets 

put in the message body of a SIP message, in UL the XML message contained in the message body needs to be 

explicitly decoded in TTCN. By defining the XML message body as a charstring the SIP definitions are independent 

from any XSD definitions and a specific XSD definition needs to be known only when it is really used. 

In detail the message body for SIP messages is defined as: 



type charstring XmlBody; 

type union MessageBody { 

SDP_Message sdpMessageBody, 



XmlBody 
MIME_Message 
charstring 
charstring 



xmlBody, 

mimeMessageBody, 
sipfrag, 
textplain. 



SimpleMsgSummarysimpleMsgSummary, 



}; 



octetstring 



smsMessage 



NOTE: In contrast to SIP and SDR definitions which are commonly defined by ETSI the definition of the 

message body is project specific i.e. other IIVIS test projects at ETSI may use different definitions of the 
message body. 



7.3.5 Additional requirements for codec implementations (SDP Body) 

The Session Description Protocol is defined in RFC 4566. 

The 'type' fields (such as 'v' and 'o' are not represented). 

For the defined attributes, the att-field is also not represented (e.g. 'curr' is not represented in 
SDP_attribute_curr). 

The Messages which are not of interest to a test suite are left undecoded as a charstring and will not be further 
structured. 

7.3.5.1 Differences between BNF - SDP Type Mapping 

In normal cases the mapping is straight forward. Below are the exceptions which differ. 

The numerical fields in the origin-field, the time-field and the timezone field have been defined as charstring 
because they may not fit into a 32-bit signed integer. 



BNF Rules of RFC 4566 


TTCN 3 Type Mapping 


origin = username 
sess-id 
sess-version 
nettype 
addrtype 
unicast-address 


type record SDPOrigin { 

charstring username, 
charstring sessionjd, 
charstring session_version, 
charstring netjype, 
charstring addrtype, 
charstring addr 

} 


time-fields = start-time 
stop-time 
repeat-fields 
[ zone-adjustments] 


type record SDP_time_field { 

charstring startjime, 
charstring stop time 

) 


zone-adjustments = time 
typed-time 


type record SDPtimezone { 

charstring adjustmentjime, 
SDP typed time offset 

} 
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The zone-adjustments field in the time-fields has been included as an additional field in the top-level message 
definition. 



BNF Rules of RFC 4566 


TTCN 3 Type Mapping 


session-description = proto-version 
origin-field 
session-name-field 
information-field 
uri-field 
email-fields 
phone-fields 
connection-field 
bandwitdh-fields 
time-fields 
key-fields 
attribute-fields 
media-descriptions 


type record SDP_Message { 

integer protocol_version, 

SDP_Origin origin, 

charstring session_name, 

charstring information optional, 

charstring uri optional, 

SDP_email_list emails optional, 

SDP_phone_list phone_numbers optional, 

SDP_connection connection optional, 

SDP_bandwidth_list bandwidth optional, 

SDP_time_list times, 

SDP_timezone_list timezone_adjustments optional, 

SDP_key key optional, 

SDP_attribute_list attributes optional, 

SDP media desc list media list optional 


time-fields = start-time 
stop-time 
repeat-fields 
[ zone-adjustments] 


type record SDP_time { 

SDPJimeJield timejield, 

SDP repeat list time repeat optional 

} 



The mappings for the email-address, phone-number and connection-address fields have been simplified. 



BNF Rules of RFC 4566 


TTCN 3 Type Mapping 


email-address = address-and-comment 
/ dispname-and-address 
/ addrspec 


type record SDPcontact { 

charstring addr_or_phone, 
charstring disp name optional 

1 


phone-number = email-safe 

/ email-safe "<" phone ">" 
/ phone 


type record SDPcontact { 

charstring addr_or_phone, 
charstring disp name optional 

} 


connection-address = multicast-address 
/ unicast-address 


type record SDPconnaddr { 

charstring addr, 

integer ttl optional, 

integer num of addr optional 

1 



7.3.5.2 



Defined attributes 



The SDP_attribute type is defined as a union of the following attribute types. There is an unknown attribute given to 
decode undefined attributes with a name and value. 



SDP Attribute 


TTCN 3 Type Mapping 


cat 


type record SDP_attribute_cat { 

charstring attr value 
} 


charset 


type record SDP_attribute_charset { 

charstring attr value 
1 


conf 


type record SDP_attribute_curr { 

charstring preconditionType, 
charstring statusType, 
charstring direction 

} 


curr 


type record SDP_attribute_curr { 

charstring preconditionType, 
charstring statusType, 
charstring direction 

} 


des 


type record SDP_attribute_des { 

charstring preconditionType, 
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SDP Attribute 


TTCN 3 Type Mapping 




charstring strength, 
charstring statusType, 
charstring direction 

1 


fmtp 


type record SDP_attribute_fmtp { 

charstring attr value 

} 


framerate 


type record SDP_attribute_framerate { 
charstring attr value 
1 


inactive 


type record SDP attribute inactive { 
1 


l<eywds 


type record SDP_attribute_keywds { 

charstring attr value 
} 


lang 


type record SDP_attribute_lang { 

charstring attr value 
) 


orient 


type record SDP_attribute_orient { 

charstring attr value 

} 


ptime 


type record SDP_attribute_ptime { 

charstring attr value 
1 


quality 


type record SDP_attribute_quality { 

charstring attr value 
} 


recvonly 


type record SDP attribute recvonly { 
} 


rtcp 


type record SDP_attribute_rtcp { 

charstring attr value 
1 


rtpmap 


type record SDP_attribute_rtpmap { 

charstring attr value 

} 


sdplang 


type record SDP_attribute_sdplang { 

charstring attr value 
1 


sendrecv 


type record SDP attribute sendrecv { 

} 


sendonly 


type record SDP attribute sendonly { 
} 


Tool 


type record SDP_attribute_tool { 

charstring attr value 
1 


Type 


type record SDP_attribute_type { 

charstring attr value 
} 


Unknown 


type record SDP_attribute_tool { 

charstring name, 

charstring attr value optional 

} 



7.3.6 

FFS 



Additional requirements for codec implementations (HTTP) 



7.3.7 Additional requirements for codec implementations (XML) 

XML data schema is used in IMS conformance testing according to ETSI ES 201 873-9. No further requirements are 
necessary. 
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7.4 Requirements for codec implementations (DHCP, DNS) 

The DHCP/DNS codec converts TTCN descriptions into/from octet streams as specified in the RFCs. The TTCN type 
defintions for DHCP/DNS types closely follow the data formats defined in the corresponding RFCs (RFC 1035, RFC 
1533, RFC 2131, RFC 3315, RFC 3319 and RFC 3361). 

As a special case, when the TTCN length field in a DHCP/DNS record is set to the encoder shall compute the proper 
length value during encoding. 



8 



Design consideration 



8.1 Bearer Configurations for IIVIS Testing 



8.1 .1 Bearer Information for UTRAN 



Bearerlnfo 


RANTech = UTRAN FDD 


Description 


1 


34.108, clause 6.10.2.4.1.56 


To be used for IMS Signalling 
only 


2 


34.108, clause 6.10.2.4.6.6 


Not supported in Rel-5 


3 


34.108, clause 6.10.2.4.6.7 


Not supported in Rel-5 


4 


25.993, clause 7.1.122 


Only supported in Rel-5 


5 


25.993, clause 7.1.124 


Not supported in Rel-5 



8.1 .2 Bearer Information for GERAN 

No specific bearer information has yet been defined. The QoS to be used is therefore dependant on the media 
applications supported by the UE. 

8.1 .3 Bearer Information for E-UTRA 



Bearerlnfo 


RANTech = E-UTRA FDD 


Description 


1 


36.508, clause 6.6.1 Reference 
default EPS bearer context #1 


For IIVIS Signalling and media 
text 


2 


36.508, clause 6.6.2 Reference 
dedicated EPS bearer context #1 


For IIVIS media voice and video 


3 


36.508, clause 6.6.1 Reference 

default EPS bearer context #1 , 

except that it is on the Emergency 

Call PDN 


Default bearer for emergency call 
signalling 


4 


36.508, clause 6.6.2 Reference 
dedicated EPS bearer context #1 


Dedicated bearer for emergency 
voice media 



8.2 Security 

TBD. 

8.3 External Function Definitions 

The following external functions are required to be implemented by the SS. 
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TTCN3 External Function 


Name 


fx MD5 Hex 


Description 


to calculate the MD5 Message-Digest Algorithm according to RFC 1231 


Parameters 


data octetstring 


Return Value 


octetstring 



Additionally, the following external function is used as defined in TS 36.523-3 [30]: 
fx_GetSystemTime 

8.4 AT commands 

No AT commands have yet been defined for IMS operations 
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Annex A (normative): 
Abstract Test Suites (ATS) 

This annex contains the approved ATSs. 



The ATSs have been produced using the Testing and Test Control Notation version 3 (TTCN3) according to 
ES 201 873 [12]. 



A.1 Version of specifications 

Table A.l shows the version of the test specifications which the delivered ATSs are referred to. 

Table A.1 : Versions of the test and Core specifications 



Core specifications 


3GPPTS 24.229 [11] 


Test specifications 


3GPP TS 34.229-1 [5] 


3GPP TS 34.229-2 [6] 


3GPPTS 34.123-3 [2] 


3GPP TS 36.523-3 [30] 
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A.2 IMS-CC ATS 



Table A.2: IMS-CC TTCN test cases 



Test case 


Description 


■ 


■ 


7.1 


P-CSCF Discovery via PDP Context 


7.2 


P-CSCF Discovery via DHCP - IPv4 


7.3 


P-CSCF Discovery via DHCP - IPv4 (UE Requests P-CSCF discovery via PCO) 


7.4 


P-CSCF Discovery by DHCP - IPv6 


7.5 


P-CSCF Discovery by DHCP-IPv6 (UE Requests P-CSCF discovery by PCO) 


7.6 


P-CSCF Discovery by DHCP - IPv6 (UE does not Request P-CSCF discovery by 
PCO, SS includes P-CSCF Address(es) in PCO) 


8.1 


Initial registration 


8.2 


User Initiated Re-Registration 


8.3 


IVIobile Initiated Deregistration 


8.4 


Invalid behaviour- 423 Interval too brief 


8.10 


Initial registration using GIBA 


8.12 


User initiated re-registration using GIBA 


8.13 


User initiated de-registration using GIBA 


9.1 


Invalid Behaviour- MAC Parameter Invalid 


9.2 


Invalid Behaviour - SON out of range 


10.1 


Invalid Behaviour - 503 Service Unavailable 


11.1 


Network-initiated deregistration 


11.2 


Network initiated re-authentication 


12.12 


IVIO MTSI Voice Call Successful with preconditions 


12.13 


IVIT MTSI speech call 


13.1 


SigComp in the Initial registration 


15.8 


Communication Forwarding on non reply: MO call initiation 


15.11 


MO Call Hold without announcement 


15.12 


MI Call Hold without announcement 


15.27 


Communication Waiting and answering the call 


15.28 


Communication Waiting and cancelling the call 


16.1 


Speech AMR, indicate all codec modes 


16.2 


Speech AMR, indicate selective codec modes 


18.1 


Mobile Originating SMS 


18.2 


Mobile Terminating SMS 



The ATS is contained in an ASCII file (IMS_CC.ttcn) which accompanies the present document. 

A.2.1 Void 
A.2.2 Void 
A.2.3 Optional IP-CAN TTCN 2++ interface 

FFS. 
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Annex B (normative): 
Partial IXIT proforma 



Notwithstanding the provisions of the copyright related to the text of the present document, The Organizational Partners 
of 3GPP grant that users of the present document may freely reproduce the partial IXIT proforma in this annex so that it 
can be used for its intended purposes and may further publish the completed partial IXIT. 



B.O Introduction 

This partial IXIT proforma contained in the present document is provided for completion, when the related Abstract 
Test Suite is to be used against the Implementation Under Test (lUT). 

Text in italics is comments for guidance for the production of an IXIT, and is not to be included in the actual IXIT. 

The completed partial IXIT will normally be used in conjunction with the completed ICS, as it adds precision to the 
information provided by the ICS. 



B.1 Parameter values 



Table B.I : PIXIT 



Parameter name 


Description 


Type 


Default value 


Supported value 


px_Associ atedlel U ri 


TEL URI for the user 


charstring 


Set as record 3 
in EFiMPu as 
defined in TS 
34.229-1 [5] 


TEL URI 


px_AuthAMF 


Autlientication IVIanagement Field (16 
bits) 


bitstring (16) 


'0000000000000 
OOO'B 


The value shall be 
different from 
'1111 1111 1111 
1111'B 
(AMFresynch) 


pxAutliK 


Autlientication Key (128 bits) 


bitstring 
(128) 


'0101111001001 
0101011001101 
0110001001000 
1001101110101 
1101001010101 
1101110100000 
0100101110011 
0011111000011 
0000100110100 
11000101001'B 




px_AuthN 


Length of Extended value 

min 31 , max 127 (TS 34.108 cl. 8.1 .2) 


integer 


127 




px_AuthRAND 


Authentication / Random challenge 
(128 bits) 


bitstring 
(128) 


'01010101. ..01' 
B 




px Bearerlnfol 


Initial Bearer to be used 


integer 


1 




px_Bearerlnfo2 


Bearer to be used for Secondary PDF 
Context 


integer 


2 




pxCalleeUri 


URI of Callee, send in INVITE 


charstring 


"sip:User- 
B@3gpp.org" 




pxCalleeContactUri 


URI to be used to contact Callee 


charstring 


"sip:User- 
B@3gpp.org" 




px_Cellld 


UTRA or EUTRA cell Id 


charstring 


'"001010001000 
0001" 


See TS 24.229 
clause 7.2A.4.3 


px_CiphAlgo_Def 


Ciphering Algorithm 


CiphAlgo 


nociph 


enumerated type: 
des_ede3_cbc, 
aes cbc or nociph 


px_CS_emergency_call_RA 


RAT used for CS Emergency calls 


RANTech 


UTRA FDD 


enumerated type: 
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Parameter name 


Description 


Type 


Default value 


Supported value 


T 








GERAN, 
UTRA FDD, 
UTRA TDD, 
EUTRA FDD, 
EUTRA TDD, 
C2K IxRTT 


px_DHCPServer_IPAddr 


IP address of DHCP server 
(in v4 or v6 format) 


IPAddr 


"10.122.11.33" 




px_DNS_DomainName 


DNS server fully qualified domain name 
(FQDN) 


charstring 


"dnsserver.3gpp. 
org" 




px_DNSServer_IPAddr 


IP address of DNS server 
(in v4 or v6 format) 


IPAddr 


"10.122.11.33" 




px_FeatureParamValue 


Feature Parameter Value 


charstring 


"+g.3gpp.app_re 

f="urn%3Aurn- 

xxx%3A3gpp- 

service.ims.icsi. 

mmtel" 




pxHomeDomainName 


Home Domain Name. 

When using anISIIVI it is set to the same 

value as EFdomain. 

When not using ISIM just USIIVI the 

home domain name is derived from 

px IMS! (preceded by "sip:") 


charstring 


As defined in 
TS 34.229-1 [5] 




pxJPSecAlgorithm 


Integrity Algorithm 


IntAlgo 


hmac_md5_96 


enumerated type; 
hmac_md5_96, 
hmac sha 1 96 


px_P_CSCF_DomainName 


P-CSCF fully qualified domain name 

(FQDN) 

When an ISIM is used this is set to the 

same value as the content of EFp-cscf- 


charstring 


As defined in TS 
34.229-1 [5] 




px P CSCF DomainName 
_2 


Additional P-CSCF FQDN (Full 
Qualified Domain Name) for special 
tests 


charstring 


"pcscf2.3gpp.org 




px P CSCF DomainName 
_3 


Additional P-CSCF FQDN (Full 
Qualified Domain Name) for special 
tests 


charstring 


"pcscf3.3gpp.org 




px_P_CSCF_IPAddr 


IP address of P-CSCF 
(in v4 or v6 format) 


IPAddr 


"10.122.11.33" 




px_P_CSCF_IPAddr_2 


Additional P-CSCF IPaddress for 

special tests 

(in v4 or v6 format) 


IPAddr 


"10.122.11.34" 




px_P_CSCF_lPAddr_3 


Additional P-CSCF IPaddress for 

special tests 

(in v4 or v6 format) 


IPAddr 


"10.122.11.35" 




pxPcscf 


P-CSCF fully qualified domain name 
that resolves to the IP address of SS 


charstring 


"pcscf.3gpp.org" 




px_PeerUE_IPAddr 


IP address of peer UE 
(in v4 or v6 format) 


IPAddr 


"10.122.11.55 




px_Port_pc 


Protected Client port at the SS 
(simulated P-CSCF) 


integer 


5061 




px_Port_ps 


Protected Server port at the SS 
(simulated P-CSCF) 


integer 


5062 




px_Port_ps_NoSec 


Unprotected Server port at the SS 
(simulated P-CSCF) 


integer 


5060 




px_Private_Userld 


Private User Identity. 

When usingan ISIM this is set to the 

same value as EFimpi. 

When ISIM is not used just USIM the 

private user identity is derived from 

px IMSI. 


charstring 


As defined in TS 
34.229-1 [5] 




px_PublicUserldentity1 


Public User Identity. 

It is set to the same value as the first 

record in EFimpu- 


charstring 


As defined in TS 
34.229-1 [5]" 




px_PublicUserldentity2 


It is set to the same value as the 
second record in EFimpu. 


Charstring 


As defined in TS 
34.229-1 [5] 




px PublicUserldentityS 


It is set to the same value as the third 


Charstring 


As defined in TS 





£75/ 



3GPP TS 34.229-3 version 9.8.0 Release 9 



44 



ETSI TS 134 229-3 V9.8.0 (2013-07) 



Parameter name 


Description 


Type 


Default value 


Supported value 




record in EFimpu- 




34.229-1 [5] 




px_RANTech 


RAN Technology 


RANTech 


UTRAN_FDD 


enumerated type: 
GERAN, 
UTRA FDD, 
UTRA TDD, 
EUTRA FDD, 
EUTRA TDD 


px_Scscf 


S-GSGF fully qualified domain name 
that does not resolve to the IP address 
ofSS 


charstring 


"scscf@3gpp.or 

g" 




px_SS_SipUri 


SIP URI with IP Address or FQDN of 
SS (simulated P-CSCF) 


charstring 


"sip:pcscf.3gpp. 
org" 




px_TempGRUUForUE 


Temporary GRUU for UE 


charstring 


"sip:tgruu.7hs==j 
d7vnzga5w7fajs 
c7- 
ajd6fabz0f8g5@ 




pxUEInstanceld 


UE Instance Identity 


charstring 


"<urn:uuid:0000 

0000-0000- 

1000-8000- 

000A95A0E128 

>" 




px_UE_IPAddr 


IP address assigned to UE 
(in v4 or v6 format) 


IPAddr 


"10.122.11.145" 




px_UEwitlilSIM 


true UE has ISIM 
false UE has USIM only 


boolean 






px UeWithSIM 


UE has a SIM inserted 


boolean 


false 




pxjDsi_SI\/ISG 


The Public Service Identity of the 
SIVISC this is set to the same value as 
the first record in EFpsismsc as defined 
in TS 31.121 [XX]. 


charstring 


As defined in TS 
34.229-1 [5] 




px_SIVISC_addr 


Short message service centre address. 
When ISIM is used this is the same 
value as the "TP Service Centre 
Address" field in EFsmsp- 


charstring 


As defined in TS 
34.229-1 [5] 





B.1 .1 SDP parameters for MT call test case 

This clause contains parameters to describe one to three media that the SS will propose to the UE in the INVITE 
Request. This information shall be compatible with the UE's capabilities. 

Table B.1.1 : SDP parameters for MT call 



Parameter name 


Description 


Type 


Default value 


Supported value 


px NumberOfMedia 


Number of media description 


integer 


1 


1,2,3 


For each media description, ttie following parameters shall be supplied: 


px_Media 


Media type 


charstring 


"audio" 


audio, video, text, 

application, 

message 


px_MediaPort 


Transport port to which the media 
stream is sent 


integer 


49230 


Integer within the 
range 491 52- 
65535 


pxProto 


Transport protocol 


charstring 


"RTP/AVP" 


UDP, RTP/AVP, 
RTP/SAVP, TCP, 
RTP/AVPF, 
TCP/TLS 


px FmtNumber 


Number of Media format description 


integer 


3 




px_FmtValues 


Value of each media format description 
(in a comma separated list) 


charstring 


"96, 97, 98" 




px_Bandwidth 


Bandwidth value for b=AS (only if 
RTP/RTCP is used) 


integer 


75 




px_RS_Bandwidth 


Bandwidth value for b=RS (only if 
RTP/RTCP is used) 


integer 


75 
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Parameter name 


Description 


Type 


Default value 


Supported value 


px_RR_Bandwidth 


Bandwidth value for b=RR (only if 
RTP/RTCP is used) 


integer 


75 




px_AttribNumber 


Number of attribute ("a=") lines 
(excluding 'curr' and 'des' lines) 


integer 


4 




px_AttribValues 


Value of each of the attribute lines, 
excluding 'curr' and 'des' lines (in a 
comma separated list). 


charstring 


"rtpmap:96 

L8/8000, 

rtpmap:97 

LI 6/8000, 

rtpmap:98 

LI 6/1 1025/2, 

maxptime:80" 




px_LocalDir 


Direction tag for desired local resource 


charstring 


"sendrecv" 


sendrecv, send, 
recv 


pxRemoteDir 


Direction tag for desired remote 
resource 


charstring 


"sendrecv" 


sendrecv, send, 
recv 



B.2 MMI Commands 

Table B.3 requests additional information needed for the execution of the MMI commands used in the ATS. 

Table B.2. 1-1: Common MMI Commands 



Please De-REGISTER 



Please initiate a Call to <callee contact address> 



Please initiate an Emergency Call 



Please accept IVITSI call 



Please accept MIS! text 



Please set call on hold 



Please resume call 



Please activate Message Wait Indication 



Please trigger UE to send an SIVIS 



Please trigger registration of second IMPU 



Please trigger registration of third IIVIPU" 



Please switch off the UE (NOTE 1 ) 



Please switch on the UE (NOTE 1) 



NOTE 1: not used for 36.523 test model ace. to clause 5.6. 
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Table B.2.1-2: MMI Commands for configuration of supplementary services 



Pease activate 


ORIGINATING IDENTIFICATION PRESENTATION 


(Userld <public user id>) 


ORIGINATING IDENTIFICATION RESTRICTION 


TERMINATING IDENTIFICATION PRESENTATION 


TERMINATING IDENTIFICATION RESTRICTION 


COMMUNICATION FORWARDING 


UNCONDITIONAL 


NO ANSWER 


BUSY 


NOT REGISTERED 


NOT REACHABLE 


INCOMING COMMUNICATION BARRING 


EXCEPT SPECIFIC USER 


ANONYMOUS USERS 


COMMUNICATION BARRING WHILE ROAMING 


Pease deactivate 


ORIGINATING IDENTIFICATION PRESENTATION 


(Userld <public user id>) 


ORIGINATING IDENTIFICATION RESTRICTION 


TERMINATING IDENTIFICATION PRESENTATION 


TERMINATING IDENTIFICATION RESTRICTION 


COMMUNICATION FORWARDING 


UNCONDITIONAL 


NO ANSWER 


BUSY 


NOT REGISTERED 


NOT REACHABLE 


INCOMING COMMUNICATION BARRING 


EXCEPT SPECIFIC USER 


ANONYMOUS USERS 


COMMUNICATION BARRING WHILE ROAMING 
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Annex C (informative): 
Additional information to IXIT 



Notwithstanding the provisions of the copyright related to the text of the present document, The Organizational Partners 
of 3GPP grant that users of the present document may freely reproduce the IXIT proforma in this annex so that it can be 
used for its intended purposes and may further publish the completed IXIT. 



Additional information may be provided when completing the IXIT questions listed in annex A. 

C.1 Identification Summary 

Table C.l is completed by the test laboratory. The item "Contract References" is optional. 

Table C.I : Identification Summary 



IXIT Reference Number 




Test Laboratory Name 




Date of Issue 




Issued to (name of client) 




Contract References 







C.2 Abstract Test Suite Summary 

In table C.2 the test laboratory provides the version number of the protocol specification and the version number of 
ATS which are used in the conformance testing. 

Table C.2: ATS Summary 



Protocol Specification 


3GPP TS 24.229 


Version of Protocol Specification 




Test Specification in prose 


3GPP TS 34.229-1 


Version of TSS & TP Specification 




ATS Specification 


3GPP TS 34.229-3 


Version of ATS Specification 




Abstract Test Method 


Distributed Test IVIethod 
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C.3 Test Laboratory 

C.3.1 Test Laboratory Identification 

The test laboratory provides the following information. 

Table C.3: Test Laboratory Identification 



Name of Test Laboratory 




Postal Address 




Office address 




e-mail address 




Telephone Number 




FAX Number 





C.3. 2 Accreditation status of the test service 

The test laboratory provides the following information. 

Table C.4: Accreditation status of the test service 



Accreditation status 




Accreditation Reference 





C.3.3 IVIanager of Test Laboratory 

The test laboratory provides the information about the manager of test laboratory in table C.5. 

Table C.5: Manager of Test Laboratory 



Name of Manager of Test Laboratory 




e-mail address 




Telephone Number 




FAX Number 




E-mail Address 





C.3.4 Contact person of Test Laboratory 

The test laboratory provides the information about the contact person of test laboratory in table C.6. 

Table C.6: Contact person of Test Laboratory 



Name of Contact of Test Laboratory 




e-mail address 




Telephone Number 




FAX Number 




E-mail Address 
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C.3.5 Means of Testing 



In table C.7, the test laboratory provides a statement of conformance of the Means Of Testing (MOT) to the reference 
standardized ATS, and identifies all restrictions for the test execution required by the MOT beyond those stated in the 
reference standardized ATS. 

Table C.7: Means of Testing 
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C.3.6 Instructions for Completion 



In table C.8, the test laboratory provides any specific instructions necessary for completion and return of the proforma 
from the client. 

Table C.8: Instruction for Completion 




C.4 Client 

C.4.1 Client Identification 

The client provides the identification in table C.9. 

Table C.9: Client Identification 



Name of Client 




Postal Address 




Office Address 




Telephone Number 




FAX Number 





C.4. 2 Client Test Manager 

In table C.IO the client provides information about the test manager. 

Table CIO: Client Test Manager 



Name of Client Test Manager 




Telephone Number 




FAX Number 




E-mail Address 
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C.4.3 Client Contact person 

In table C. 1 1 the client provides information about the test contact person. 

Table C.11 : Client Contact person 



Name of Client contact person 




Telephone Number 




FAX Number 




E-mail Address 





C.4.4 Test Facilities Required 



In table C. 12, the client records the particular facilities required for testing, if a range of facilities is provided by the test 
laboratory. 

Table C.12: Test Facilities Required 
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C.5 System Under Test 
C.5.1 SUT Information 

The client provides information about the SUT in table C.13. 

Table C.13: SUT Information 



System Name 




System Version 




SCS Reference 




lUlachine Configuration 




Operating System Identification 




lUT Identification 




ICS Reference for the lUT 





C.5.2 Limitations of the SUT 

In table C. 14, the client provides information explaining if any of the abstract tests cannot be executed. 

Table C.14: Limitation of the SUT 
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C.5.3 Environmental Conditions 

In table C. 15 the client provides information about any tighter environmental conditions for the correct operation of the 
SUT. 

Table C.15: Environmental Conditions 




C.6 Ancillary Protocols 

This clause is completed by the client in conjunction with the test laboratory. 

In the following tables, the client identifies relevant information concerning each ancillary protocol in the SUT other 
than the lUT itself. One table for one ancillary protocol. 

Based on the MOT the test laboratory should create question proforma for each ancillary protocol in the blank space 
following each table. The information required is dependent on the MOT and the SUT, and covers all the addressing, 
parameter values, timer values and facilities (relevant to ENs) as defined by the ICS for the ancillary protocol. 

C.6.1 Ancillary Protocols 1 

Table C.16: Ancillary Protocol 1 



Protocol Name 




Version number 




ICS Reference (optional) 




IXIT Reference (optional) 




PCTR Reference (optional) 
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C.6.2 Ancillary Protocols 2 



Table C.I 7: Ancillary Protocol 2 



Protocol Name 




Version number 




ICS Reference (optional) 




IXIT Reference (optional) 




PCTR Reference (optional) 
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Annex D (informative): 
PCTR Proforma 



Notwithstanding the provisions of the copyright related to the text of the present document, The Organizational Partners 
of 3GPP grant that users of the present document may freely reproduce the PCTR proforma in this annex so that it can 
be used for its intended purposes and may further publish the completed PCTR. 



PROTOCOL 

Conformance Test Report 

(PCTR) 

Universal Mobile Telecommunication System, UMTS, 

User Equipment-Network Access 

Layer 3 Signalling Functions 



Test Candidate 




Name : 


BUT name 


Model : 


model 


HA/V version : 


hw 


SA/V version 


sw 


Serial No. : 


serienr 



Client 




Name : 




Street / No. 




Postal Code / City: 




Country 





This Test Report shall not be reproduced except in full without the written permission 
of TEST LAB REFERENCE, and Shall not be quoted out of context. 



ETSI 
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Annex E (informative): 

TTCN3 style guide for 3GPP IMS ATS 

For IMS conformance tests, the style guide of 36.523-3[30], Annex B shall be applied 
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Annex F (informative): 
BNF IVIessage Definitions 

The BNF definitions required for the ATS are defined in the following RFCs: 

3261, 3262, 3265, 3311, 3313, 3323, 3325, 3326, 3327, 3329, 3428, 3455, 3515, 3608, 3840, 3841, 3891, 3892, 3903, 
3911,4028. 
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Annex G (Normative): 

SIP Type Definitions and XSD References 

The XSD references listed in this Annex are imported in the Test Suite. 



XML Schema 


RFC 


Name space 


Modifications 


reginfo 


RFC 3680 


urn:ietf:params:xml:ns:reginfo 


"http://www.w3.org/2001/03/xml.xsd" to be 
replaced by 'xml.xsd' 


conference-info 


RFC 4575 


urn:ietf:params:xml:ns:conference-info 




gruuinfo 


RFC 5628 


urn:ietf:params;xml:ns:gruuinfo 





Additionally the Test Suite imports the following modules of ETSF's LibSip (the modules are store in ETSF's SIP 
library repository; FFS): 



Module 


Revision 


LibSip SDPTypes 


FFS 


LibSip SimplelVlsgSummaryTypes 


FFS 


LibSip SIPTypesAndValues 


FFS 
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Annex H (informative): 
Change history 



lUleet- 
ing 


TSG doc 


CR 


Rev 


Subject 


Cat 


Old 
vers 


New 
vers 


WGdoc 


RP-31 


RP-060054 


- 


- 


Update to version 1 .0.0 and present to RAN#31 for 
information 


- 


- 


1.0.0 


R5-060513 


RP-34 


RP-060664 


- 


- 


Present version 1.3.0 to RAN#34 for information 


- 


- 


1.3.0 


R5-063500 


RP-35 


RP-070010 


- 


- 


Presented as version 2.0.0 for approval to go under 
revision control 






2.0.0 


R5-070456 


- 


- 


- 


- 


Upgraded to version 5.0.0 by the 3GPP support 


- 


- 


5.0.0 


- 


RP-36 


RP-070352 


0001 


- 


Addition of IMS-CC test case 8.6 to IMS CC ATS 
VI .3.0 


F 


5.0.0 


5.1.0 


R5S070101 


RP-36 


RP-070353 


0002 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose), 
Annex A 


F 


5.0.0 


5.1.0 




RP-37 


RP-070594 


0003 


- 


Extension to TTCN ASP DeactivatePDPContextReq 


F 


5.1.0 


5.2.0 


R5-072509 


RP-37 


RP-070594 


0004 


- 


IMS CC / PIXIT parameter px_Cellld 


F 


5.1.0 


5.2.0 


R5-072546 


RP-38 


RP-070870 


0007 




Addition of IMS-CC test case 8.5 to IMS CC ATS 
V5.1.0 


B 


5.2.0 


5.3.0 


R5S070489 


RP-38 


RP-070870 


0008 




Addition of IMS-CC test case 8.7 to IMS CC ATS 
V5.3.0 


B 


5.2.0 


5.3.0 


R5S070259 


RP-38 


RP-070870 


0009 




Addition of IMS-CC test case 9.1 to IMS CC ATS 
V5.3.0 


B 


5.2.0 


5.3.0 


R5S070261 


RP-38 


RP-070889 


0010 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose), 
Annex A 


F 


5.2.0 


5.3.0 




RP-38 


RP-070869 


0006 




Production of 34.229-3 pointer version in Rel-5 
pointing to Rel-6 version 


F 


5.2.0 


5.3.0 


R5-073439 


RP-38 


RP-070869 


0005 




Addition of an MMI command 


F 


5.2.0 


6.0.0 


R5-073046 


RP-39 


RP-080098 


0011 




Update of MMI command strings 


F 


6.0.0 


6.1.0 


R5-080041 


RP-39 


RP-080089 


0012 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose). 
Annex A 


F 


6.0.0 


6.1.0 




RP-39 


RP-080094 


0013 




Addition of IMS-CC test case 7.2 to IMS CC ATS 
V5.3.0 


B 


6.0.0 


6.1.0 


R5S070535 


RP-39 


RP-080094 


0014 




Addition of IMS-CC test case 10.1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070549 


RP-39 


RP-080094 


0015 




Addition of IMS-CC test case 8.3 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070545 


RP-39 


RP-080094 


0016 




Addition of IMS-CC test case 8.2 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070543 


RP-39 


RP-080094 


0017 




Addition of IMS-CC test case 7.6 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070539 


RP-39 


RP-080094 


0018 




Addition of IMS-CC test case 7.4 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070537 


RP-39 


RP-080094 


0019 




Addition of IMS-CC test case 1 1 .1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070551 


RP-39 


RP-080094 


0020 




Additionof IMS-CC test case 14.1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070555 


RP-39 


RP-080094 


0021 




Additionof IMS-CC test case 13.1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070553 


RP-39 


RP-080094 


0022 




Addition of IMS-CC test case 8.4 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070547 


RP-39 


RP-080094 


0023 




Addition of IMS-CC test case 8.1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070541 


RP-39 


RP-080094 


0024 




Addition of IMS-CC test case 7.1 to IMS CC ATS 
V5.1.0 


B 


6.0.0 


6.1.0 


R5S070491 


RP-39 


RP-080094 


0025 




Common corrections to IMS-CC test cases 


F 


6.0.0 


6.1.0 


R5S070534 


RP-40 


RP-080369 


0027 




Correction to regular expressions in IMS 


F 


6.1.0 


7.0.0 


R5S080036 


RP-40 


RP-080369 


0028 




IMS ATS / handling of P-Access-Network-lnfo header 
over non secure ports 


F 


6.1.0 


7.0.0 


R5S080063 


RP-40 


RP-080369 


0029 




IMS ATS / test case 9.1 / handling of authorization 
header in Register messages 


F 


6.1.0 


7.0.0 


R5S080085 


RP-40 


RP-080376 


0030 




Extend test model supporting XCAP test 


F 


6.1.0 


7.0.0 


R5-081036 


RP-41 


RP-080654 


0031 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose). 
Annex A 


F 


7.0.0 


7.1.0 




RP-41 


RP-080615 


0032 




Addition of IMS-CC test case 9.2 to IMS CC ATS 
v.7.0.0 


F 


7.0.0 


7.1.0 


R5S080115 


RP-41 


RP-080615 


0033 




Addition of IMS-CC test case 7.3 to IMS CC ATS 


F 


7.0.0 


7.1.0 


R5S080114 
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Meet- 
ing 


TSG doc 


CR 


Rev 


Subject 


Cat 


Old 
vers 


New 
vers 


WGdoc 










v.7.0.0 










RP-41 


RP-080615 


0034 




Implementation of IPCanCtI code as a parallel test 
component 


F 


7.0.0 


7.1.0 


R5S080138 


RP-41 


RP-080615 


0035 




Addition of IMS-CC test case 8.9 to IMS CC ATS 
v.6.2.0 


F 


7.0.0 


7.1.0 


R5S080145 


RP-41 


RP-080615 


0036 




Addition of IMS-CC test case 8.8 to IMS CC ATS 
v.6.2.0 


F 


7.0.0 


7.1.0 


R5S080143 


RP-41 


RP-080615 


0037 




Addition of IMS-CC test case 7.5 to IMS CC ATS 


F 


7.0.0 


7.1.0 


R5S080151 


RP-41 


RP-080740 


0038 




Update of TS 34.229-3 from Rel-6 to Rel-7 


F 


7.1.0 


7.2.0 


R5-083065 


RP-42 


RP-080959 


0039 




Correction of HW Type and HW Length fields in 
DHCP response messages 


F 


7.1.0 


7.2.0 


R5S080171 


RP-42 


RP-080959 


0040 




Minor correction of Route header template in the 
initial Register message 


F 


7.1.0 


7.2.0 


R5S080168 


RP-43 


RP-090210 


0041 




Update of TS 34.229-3 from Rel-7 to Rel-8 


F 


7.2.0 


8.0.0 


R5-090765 


RP-43 


RP-090210 


0042 




IMS CC ATS / Improvement: Stopping test case 
execution once a PTC fails 


F 


8.0.0 


8.1.0 


R5S090019 


RP-43 


RP-090210 


0043 




IMS CC ATS / Handling of non-default port number in 
the Contact Header 


F 


8.0.0 


8.1.0 


R5S090018 


RP-43 


RP-090210 


0044 




IMS CC ATS / Handling of Contact Header 


F 


8.0.0 


8.1.0 


R5S090005 


RP-43 


RP-090210 


0045 




IMS CC / Minor corrections on test 1 1 .2 (re- 
authentication) 


F 


8.0.0 


8.1.0 


R5S090004 


RP-43 


RP-090210 


0046 




IMS CC / Addition of test case 1 1 .2 to the IMS ATS 


F 


8.0.0 


8.1.0 


R5S080313 


RP-43 


RP-090210 


0047 




IMS CC test model / Addition of new ASP to 
reconfigure IP Layer 


F 


8.0.0 


8.1.0 


R5-090032 


RP-43 


RP-090210 


0048 




Removal of an unused pixit and other routine updates 


F 


8.0.0 


8.1.0 


R5-090056 


RP-46 


RP-091156 


0049 


- 


CR to 34.229-3 (prose) update to v820 


F 


8.1.0 


8.2.0 


- 


RP-47 


RP-100146 


0050 


- 


CR to 34.229-3 (prose) update to v830 


F 


8.2.0 


8.3.0 




RP-47 


RP-100155 


0051 


- 


Correction of IMS test model for XCAP-based SS test 


F 


8.2.0 


8.3.0 


R5-1 00087 


RP-47 


RP-100140 


0052 


- 


Add bearer information for E-UTRA 


F 


8.2.0 


8.3.0 


R5-100414 


RP-48 


RP-100514 


0053 


- 


CR to 34.229-3 (prose) update to v840 


F 


8.3.0 


8.4.0 


- 


RP-48 


RP-100511 


0054 


- 


Update IMS test model 


F 


8.3.0 


8.4.0 


R5-1 03382 


RP-50 


RP-101146 


0055 


- 


Routine maintenance of TS 34.229-3 


F 


8.4.0 


8.5.0 


R5-1 06088 


RP-50 


RP-101150 


0056 


- 


CR to 34.229-3 update to v850 


F 


8.4.0 


8.5.0 


- 


RP-51 


RP-110165 


0057 


- 


Mapping of some PIXIT parameters to ISIM EFs - 3 
IMPU 


F 


8.5.0 


8.6.0 


R5-1 10694 


RP-51 


RP-110169 


0058 


- 


CR to 34.229-3 (prose) update to v860 


F 


8.5.0 


8.6.0 




RP-52 


RP-1 10651 


0059 


- 


Removal of technical content in 34.229-3 v8.6.0 and 
substitution with pointer to the next Release 


F 


8.6.0 


8.7.0 


R5-1 12246 


RP-52 


RP-1 10651 


0060 


- 


Routine maintenance 


F 


8.6.0 


9.0.0 


R5-1 12648 


RP-52 


RP-1 10655 


0061 


- 


CR to 34.229-3 (prose) update to v870 


F 


8.6.0 


9.0.0 


- 


RP-53 


RP-1 11 160 


0062 


- 


CR to 34.229-3 (prose) update to v910 


F 


9.0.0 


9.1.0 




RP-54 


RP-1 11 584 


0063 


- 


Routine maintenance and updates for IMS ASP 


F 


9.1.0 


9.2.0 


R5-1 15670 


RP-55 


RP-120187 


0064 


- 


CR to 34.229-3 (prose) update to v930 


F 


9.2.0 


9.3.0 




RP-56 


RP-1 20649 


0065 


- 


Routine maintenance and updates 


F 


9.3.0 


9.4.0 


R5-121090 


RP-56 


RP-1 20802 


0066 


- 


Correction to IMS CC test cases / IPv6 address 
handling 


F 


9.3.0 


9.4.0 


R5S120108 


RP-57 


RP-1 211 03 


0067 


- 


34229-3: Routine maintenance and updates 


F 


9.4.0 


9.5.0 


R5-1 23085 


RP-57 


RP-121221 


0068 


- 


TTCN IMS correction 


F 


9.4.0 


9.5.0 


R5s1 20530 


RP-57 


RP-121221 


0069 


- 


Addition of GCF WI-031 IMS test case 8.1 


F 


9.4.0 


9.5.0 


R5s1 20537 


RP-57 


RP-121221 


0070 


- 


Addition of GCF WI-031 IMS test case 8.12 


F 


9.4.0 


9.5.0 


R5s1 20539 


RP-57 


RP-121221 


0071 


- 


Addition of GCF WI-031 IMS test case 8.13 


F 


9.4.0 


9.5.0 


R5s1 20541 


RP-57 


RP-121221 


0072 


- 


Addition of GCF WI-128 IMS test case 1 8.1 


F 


9.4.0 


9.5.0 


R5s1 20543 


RP-57 


RP-121221 


0073 


- 


Addition of GCF WI-1 28 IMS test case 1 8.2 


F 


9.4.0 


9.5.0 


R5s1 20545 


RP-57 


RP-121221 


0074 


- 


Addition of GCF WI-1 03 IMS test case 1 6.1 


F 


9.4.0 


9.5.0 


R5s1 20547 


RP-57 


RP-121221 


0075 


- 


Addition of GCF WI-1 03 IMS test case 1 6.2 


F 


9.4.0 


9.5.0 


R5s1 20549 


RP-57 


RP-121106 


0076 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose), 
Annex A 


F 


9.4.0 


9.5.0 




RP-58 


RP-1 21 664 


0077 


- 


34229-3: Routine maintenance and updates 


F 


9.5.0 


9.6.0 


R5-125120 


RP-58 


RP-121669 


0078 


- 


Addition of GCF WI-1 03 IMS test case 12.12 


B 


9.5.0 


9.6.0 


R5s1 20605 


RP-58 


RP-121669 


0079 


- 


Addition of GCF WI-1 03 IMS test case 12.13 


B 


9.5.0 


9.6.0 


R5s1 20607 


RP-58 


RP-121669 


0080 


- 


Addition of GCF WI-1 03 IMS test case 15.11 


B 


9.5.0 


9.6.0 


R5s1 20609 


RP-58 


RP-121669 


0081 


- 


IMS TTCN correction 


F 


9.5.0 


9.6.0 


R5s1 20729 


RP-58 


RP-121669 


0082 


- 


Addition of GCF WI-1 03 IMS test case 15.8 


B 


9.5.0 


9.6.0 


R5s1 20730 


RP-58 


RP-121669 


0083 


- 


Addition of GCF WI-1 03 IMS test case 15.12 


B 


9.5.0 


9.6.0 


R5s1 20732 


RP-58 


RP-121669 


0084 


- 


Addition of GCF WI-1 03 IMS test case 1 5.27 


B 


9.5.0 


9.6.0 


R5s1 20733 


RP-58 


RP-121669 


0085 


- 


Addition of GCF WI-1 03 IMS test case 1 5.28 


B 


9.5.0 


9.6.0 


R5s1 20736 


RP-58 


RP-1 21 668 


0086 




CR to 34.229-3: Add new verified and e-mail agreed 
TTCN test cases in the TC lists in 34.229-3 (prose), 
Annex A 


F 


9.5.0 


9.6.0 




RP-59 


RP-1 301 45 


0087 


- 


34229-3: Routine maintenance and updates 


F 


9.6.0 


9.7.0 


R5-130198 


RP-59 


RP-1 301 50 


0088 


- 


Re-verification of IMS Registration test case 8.10 over 


F 


9.6.0 


9.7.0 


R5s1 20858 
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Meet- 
ing 


TSG doc 


CR 


Rev 


Subject 


Cat 


Old 
vers 


New 
vers 


WGdoc 










LTE with 36.523-3 test model 










RP-59 


RP-130150 


0089 


- 


Corrections for IMS test cases with 34.229-3 test 
model 


F 


9.6.0 


9.7.0 


R5s1 20907 


RP-59 


RP-130150 


0090 


- 


Re-verification of IMS Registration test case 8.4 over 
LTE with new 34.229-3 test model 


F 


9.6.0 


9.7.0 


R5s1 20945 


RP-59 


RP-130150 


0091 


- 


Re-verification of IMS Authentication test case 9.1 
over LTE with the new 34.229-3 test model 


F 


9.6.0 


9.7.0 


R5s1 20947 


RP-59 


RP-130150 


0092 


- 


Corrections to IMS 36523 IWD 12wk48 test suite 


F 


9.6.0 


9.7.0 


R5s1 30011 


RP-59 


RP-130150 


0093 


- 


Corrections for IMS TC 8.1 regarding IPv6 privacy 


F 


9.6.0 


9.7.0 


R5s1 30049 


RP-59 


RP-130149 


0094 


- 


CR to 34.229-3 (prose) update to v970 


F 


9.6.0 


9.7.0 


- 


RP-60 


RP-130611 


0095 


- 


34229-3: Routine maintenance and updates 


F 


9.7.0 


9.8.0 


R5-131140 


RP-60 


RP-130617 


0096 


- 


Corrections to feature parameter in MT call invitation 


F 


9.7.0 


9.8.0 


R5S130109 


RP-60 


RP-130617 


0097 




Re-verification of IMS Registration (IPSec) test case 
8.1 over LTE with 36.523-3 test model 


F 


9.7.0 


9.8.0 


R5S130133 


RP-60 


RP-130617 


0098 




Re-verification of IMS test case 8.3 over LTE with 
36.523-3 test model 


F 


9.7.0 


9.8.0 


R5S130181 


RP-60 


RP-130617 


0099 




Re-verification of IMS SMS test case 18.2 over LTE 
with 36.523-3 test model 


F 


9.7.0 


9.8.0 


R5S130183 


RP-60 


RP-130617 


0100 


- 


Corrections for IMS TC 8.1 


F 


9.7.0 


9.8.0 


R5S130187 


RP-60 


RP-130617 


0101 




Re-verification of IMS Registration test case 8.2 over 
LTE with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30233 


RP-60 


RP-130617 


0102 




Re-verification of IMS SMS test case 18.1 over LTE 
with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30235 


RP-60 


RP-130617 


0103 


- 


Correction to SIP template cr_FromWithTag 


F 


9.7.0 


9.8.0 


R5s1 30256 


RP-60 


RP-130617 


0104 




Re-verification of IMS Authentication test case 9.2 
over LTE with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30264 


RP-60 


RP-130617 


0105 




Re-verification of IMS Notification test case 1 1 .2 over 
LTE with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s 130266 


RP-60 


RP-130617 


0106 




Corrections for IMS Registration TC 8.3 over LTE with 
34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30274 


RP-60 


RP-130617 


0107 




Re-verification of IMS Subscription test case 10.1 
over LTE with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30294 


RP-60 


RP-130617 


0108 




Re-verification of IMS Registration test case 11.1 over 
LTE with 34.229-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30296 


RP-60 


RP-130617 


0109 




Re-verification of IMS Call Control test case 12.12 
over LTE with 36.523-3 test model 


F 


9.7.0 


9.8.0 


R5s1 30333 
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